Multiply interconnectable environmentally interactive character simulation module method and system

ABSTRACT

The present invention relates to a game, including a first module having a housing, a processor, a display operably coupled to the processor and an electrical contact positioned such that access is available to the electrical contact of the first module through the first module housing, and a second module having a housing, a processor, a display operably coupled to the processor and an electrical contact positioned such that access is available to the electrical contact of the second module through the second module housing, the electrical contact of the second module configured to contact the electrical contact of the first module, allowing the processor of the first module to communicate with the processor of the second module. Wherein when the processor of the second module is in communication with the processor of the first module, the first module display and the second module display are configured to each display a portion of a the game, each such portion configured to not overlap each other such portion.

RELATED APPLICATION(S)

This application is a continuation of U.S. patent application Ser. No.12/098,963 filed on Apr. 7, 2008, titled MULTIPLY INTERCONNECTABLEENVIRONMENTALLY INTERACTIVE CHARACTER SIMULATION MODULE METHOD ANDSYSTEM; which claims the benefit of U.S. patent application Ser. No.11/216,674 filed on Oct. 25, 2005 and titled MULTIPLY INTERCONNECTABLEENVIRONMENTALLY INTERACTIVE CHARACTER SIMULATION MODULE METHOD ANDSYSTEM; and U.S. Provisional Patent Application Ser. No. 60/642,565,filed Jan. 10, 2005 and titled MULTIPLY INTERCONNECTABLE ENVIRONMENTALLYINTERACTIVE CHARACTER SIMULATION MODULE METHOD AND SYSTEM. The completedisclosure of the above-identified patent applications are herebyincorporated by reference for all purposes.

FIELD OF THE DISCLOSURE

The present invention relates to portable electronic charactersimulations. More specifically, the present invention relates to aportable electronic character simulation module that interconnects withone or more other portable electronic character simulation modules. Theimage associated with a character simulation can move between anyinterconnected modules and can interact with the character simulationsof any interconnected modules. Further, the portable electroniccharacter simulation module can include orientation, sound, light, timeand/or other sensors.

BACKGROUND

Portable electronic units that house character simulations, for examplevirtual pets, gained popularity in about the last ten years,particularly with school-aged children. Typically, a virtual pet is ahand-held electronic device having a display (e.g., dot matrix LCD) andone or more buttons. An image representing a character simulation (e.g.,a fanciful/alien creature, a dog, a cat, etc.) is shown on the display,and a user can interact with the character simulation via the buttons.

In one virtual pet, interaction with a user influences the developmentand health of the character simulation. For example, a user can be ableto feed the character by pressing a feed button. If the user does notfeed the character for a certain length of time, the image displayed forthe character can change to indicate the character is hungry or indeclining health. If left unfed long enough, a simulated character caneven die. Conversely, if the user feeds the character too often, thecharacter can become fat, fail to develop to a next stage or assume aless desirable form in a next stage. Similarly, the user can be able totend to sanitary, playtime, discipline, medical and other needs of thesimulated character.

While hand-held character simulations remain popular, users desiregreater interactivity. In particular, there is a need for a hand-heldcharacter simulation that has greater interactivity with the user andthe user's environment. Further there is a need for a hand-heldcharacter simulation that has greater interactivity with other hand-helpcharacter simulations.

SUMMARY

The present invention relates to a game. The game can include a firstmodule having a housing, a processor, a display operably coupled to theprocessor and an electrical contact positioned such that access isavailable to the electrical contact of the first module through thefirst module housing, and a second module having a housing, a processor,a display operably coupled to the processor and an electrical contactpositioned such that access is available to the electrical contact ofthe second module through the

second module housing, the electrical contact of the second moduleconfigured to contact the electrical contact of the first module,allowing the processor of the first module to communicate with theprocessor of the second module. Wherein when the processor of the secondmodule is in communication with the processor of the first module, thefirst module display and the second module display are configured toeach display a portion of a the game, each such portion configured tonot overlap each other such portion.

The present invention also relates to a method of playing a game. Themethod can include connecting an electrical contact of a first module toan electrical contact of a second module, a first module processorcommunicating with a second module via the connection, viewing acharacter on a display screen on the first module, viewing a characteron a display screen on the second module, the character on the seconddisplay configured to interact with the character on the first display,and moving at least one of the first module and the second module toaffect game play.

The present invention also relates to a game. The game can include afirst module having a first electrical contact, a first processor and afirst display, the processor configured to display a first character onthe display, the character having a first set of traits, and a secondmodule having a second electrical contact, a second processor and asecond display, the processor configured to display a second characteron the display, the character having a second set of traits. Wherein thefirst electrical contact is configured to electrically couple to thesecond contact, allowing the first and second processors to communicate,wherein the processor is programmed to display a first animationsequence if the first module and the second module are arranged in afirst physical configuration, and wherein the processor is programmed todisplay a second animation sequence if the module and the second moduleare arranged in a second physical configuration, the second physicalconfiguration being different from the first physical configuration, thesecond animation sequence being different from the second animationsequence.

Additional features and advantages of the present invention aredescribed in, and will be apparent from, the following DetailedDescription of the Invention and the figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B illustrate simulated character modules in accordancewith one embodiment of the present invention.

FIG. 2 illustrates three interconnected simulated character modules inaccordance with one embodiment of the present invention.

FIGS. 3A and 3B illustrate a collection of simulated character modulesthat can only be connected in certain configurations being connected inboth a correct and incorrect manner in accordance with one embodiment ofthe present invention.

FIG. 4 illustrates a schematic block diagram of the electronicconfiguration of the simulated character module of FIG. 1.

FIGS. 5A-E illustrate images for simulated characters in accordance withone embodiment of the present invention.

FIGS. 6A-I illustrate a simulated character as it moves from module tomodule in accordance with one embodiment of the present invention.

FIG. 7 illustrates a possible configuration for interconnected modulesin accordance with one embodiment of the present invention.

FIGS. 8A-D illustrate a simulated character module and its orientationsensor in different orientations in accordance with one embodiment ofthe present invention.

FIG. 9 is a flow diagram of the process of operating a simulatedcharacter module that has a sound sensor in accordance with oneembodiment of the present invention.

FIG. 10 is a flow diagram of the process of simulating a character thatreacts to light levels in accordance with one embodiment of the presentinvention.

FIG. 11 is a flow diagram of the process of simulating a character thatreacts has different behaviors depending upon the time or date inaccordance with one embodiment of the present invention.

FIG. 12 is a flow diagram of the process for playing a game in whichsimulated characters are pieces of the game in accordance with oneembodiment of the present invention.

DETAILED DESCRIPTION

In one embodiment of the present invention, a character simulationmodule is interconnectable with one or more other character simulationmodules. Preferably, the module is directly interconnectable with up tofour other character modules and indirectly interconnectable with anunlimited number of other modules, but the limit for directly andindirectly interconnected modules can be any suitable number.

As illustrated by FIGS. 1A and 1B, the character simulation module 100is preferably substantially cube-shaped; however, the module can be anysuitable shape. Further, the module 100 is preferably suitably sized tobe hand-held (e.g., 40 mm×40 mm×40 mm, or 47 mm×47 mm×47 mm), but can beany suitable size. At least one surface 110 (e.g., a front surface) ofthe module 100 includes a display 120. The display 120 is preferably a32×32 pixel dot matrix liquid crystal display (LCD) approximately 25mm×25 mm in size, but the display 120 can be of any suitable type,resolution and size. Further, the module 100 has input devices 130 thatenable a user to interact with the module 100.

Communication devices 140 are located on one or more surfaces 150 (e.g.,a top, left, right and bottom surface) that enable the module 100 tointerconnect with other modules. Preferably, the communication devices140 and the display 120 are not on the same surface; however,communication devices 140 can be positioned on the same surface as thedisplay 120. When another module is interconnected with the module 100,communication devices 140 preferably form a physical connection with thecommunication devices of the other module. Communication devices 140 arepreferably flat metal connectors, but can be either male or femaleconnectors which both connect two modules and help hold those modules inan interconnected position. Alternatively, communication devices 140 cancommunicate wirelessly (e.g., via IR, RF, other light or sonictransmissions), and can be located on the interior of the module 100rather than at any surface.

As shown in FIG. 2, modules 100 can be interconnected. Preferably,modules can only be connected in certain configurations. For example, atop side of one module can be connectable only to a bottom side ofanother module and not any other side of that module. FIGS. 3A and 3Bshow examples of correct and incorrect, respectively, module 100interconnection when modules 100 are only connectable in certainconfigurations. In FIG. 3A, each of the illustrated interconnectionconfigurations is permitted. In contrast, in FIG. 3B, none of theinterconnections configurations illustrated are permitted.

Alternatively, modules can be interconnected in any configuration, ifdesired. For example, any side of one module can be connected to anyside of another module. Further, modules are preferably secured in placewhen interconnected by magnets; however modules can be secured in anyother suitable manner, or modules can be unsecured and free to moverelative to each other.

One or more, possibly all, input devices 130 are preferably disabled orignored when the module 100 is interconnected with another module;however, input devices 130 can remain active and continue to provide auser with the ability to provide the module 100 and/or otherinterconnected modules with input. The housing 160 can have any suitablecolor, decoration or design. Preferably, the housing 160 appearance fora particular module is created through injected plastic colors, paint orpad print; however, the appearance can be created through any othersuitable manner. Further, the housing 160 is preferably substantiallyopaque as shown in FIG. 1A; however, the housing 160 can be translucentas shown in FIG. 1B or transparent, if desired.

As illustrated in FIG. 4, a character simulation module (e.g., module100) also includes a processor 400, memory unit 410, power source 420,display 430, one or more input devices 440 and one or more communicationdevices 450. The processor 400, memory unit 410, display 430, inputdevices 440 and communication devices are connected by a bus 450, butthese components can be connected in any suitable manner (e.g., eachcomponent being directly connected to the processor). The processor 400and memory unit 410 are separate, but the memory unit 410 canalternatively be included as part of the processor 400. Similarly, powersource 420 supplies power directly to each component, but power can beprovided from the power source 420 to the other components in anysuitable manner. Further, power source 420 is preferably a battery, butcan be a DC or AC connection to a standard household power line orautomobile cigarette lighter slot or any other suitable source ofelectric power.

Processor 400 and memory unit 410 control and store a simulatedcharacter. One or more images associated with the simulated charactercan be shown on display 430. Preferably, display 430 is a virtual windowinto the simulated character's world. The behavior of the simulatedcharacter can be influenced by signals from the input devices 440 and/orthe communication devices 460.

Different simulated character modules can contain simulated charactersthat differ in their visual representation, behavior, or othercharacteristics. As a result, simulated characters can be distinguishedby their associated images or by their animated behavior. As illustratedby FIGS. 5A-B, simulated characters can have genders. An image 500resembling the general shape of a man is shown on display 510 of FIG.5A, and an image 520 resembling the general shape of a woman wearing adress and having a bow in her hair is shown on display 530 of FIG. 5B.Alternatively, simulated characters, such as the one represented by thestick figure image 540 shown on display 550 of FIG. 5C, or the onerepresented by the stick figure image 560 carrying a cane, staff orstick shown on display 570 of FIG. 5D can be genderless. Further, asillustrated by FIG. 5E, a simulated character can be an animal, such asthe image 580 resembling a dog shown on display 590.

Two similar, or even identical, appearing simulated characters can bedistinguished by animations of their behavior. For example, onecharacter hops around and another walks on its hands. Furtherdistinguishing characteristics include, but are not limited to, dancinga disco move, turning a cartwheel, doing a back flip, performing asomersault, flexing muscles, passing gas, belching, dancing with a cane,wearing a top hat, carrying a sword, shooting an arrow, firing a gun,using a lasso, winking, blowing a kiss, changing size, flying, swinging,having a beard, having long hair, having a Mohawk, having a moustache,wearing a skirt, being some kind of animal, being a plant and reading abook.

Simulated Character Mobility Between Modules

As FIGS. 6A-I illustrate, a simulated character image 600 can leave onesimulated character module and enter another. Thus, the virtual world ofthe character is expanded to include the interconnected modules. Theimage 600 associated with a character simulation can move between anyinterconnected modules. The identifying characteristics of the simulatedcharacter typically enable a viewer to track the image 600 as it movesfrom module to module. However, in some circumstances, the display ofone or more modules can be cluttered, thus hampering the ability totrack the image 600 for a particular simulated character.

Simulated character modules 602, 604, 606, 608, 610, 612, 614, 616 and618 are interconnected in a square pattern, similar to an apartmentcomplex, but can be arranged in any suitable configuration. Initially,for the sake of example, the character simulation associated withcharacter image 600 is maintained in simulated character module 610 andthe image is displayed in FIG. 6E on simulated character module 610. Theimage 600 can move to any of the interconnected modules. If thesimulated character climbs, jumps, tunnels, teleports or otherwise goesthrough the ceiling of module 610, the image 600 is displayed in module604, as illustrated in FIG. 6B.

Similarly, if the simulated character walks, hops, runs, jumps, tunnels,teleports or otherwise goes through the left wall of module 610, theimage 600 is displayed in module 608, as illustrated in FIG. 6D. If thesimulated character instead goes through the right wall or the floor,the image is displayed in module 612 as in FIG. 6F or module 616 as inFIG. 6H, respectively. Preferably, the image 600 can move directlybetween any two modules that are directly interconnected. However, somecircumstance (e.g., the rules of a game or a particular module) couldprevent the image 600 from moving directly between two directlyinterconnected modules.

Preferably, the image 600 cannot move directly to a module connectedonly indirectly to the module currently displaying the image 600. Forexample, image 600 could not move directly to module 602. Instead, toreach module 602 as illustrated in FIG. 6A, the image 600 must firstpass through either module 604 or 608. Likewise, the image 600 must movefrom either module 604 or module 612 to reach module 606, as illustratedin FIG. 6C. Similarly, if the image 600 is in module 616, it could moveto module 614 or module 618, as illustrated in FIGS. 6G and 61,respectively.

Alternatively, the image 600 is able to move directly to module 602 frommodule 610 even though the two modules are only connected indirectly.Image 600 could move directly between two indirectly connected modulesthat are even further apart (e.g., the modules do not share a side oreven a corner). For example, in the alternative configuration of modules700 illustrated in FIG. 7, the image 600 could move directly from module705 to module 710. In such an event, preferably an amount of time wouldpass between the image 600 leaving module 705 and appearing on module710. Preferably, the amount of time is approximately equal to the amountof time it would typically take the image 600 to move through the emptyspace 715 if it were filled by one or more modules 700. However, theamount of time can be any length or there can be no delay at all.Further, if the image 600 teleports from module 705 to module 710, theamount of time can be substantially the same as passes when the image600 teleports between any other two modules.

Preferably, when a character's image moves between modules, informationfor the character remains in the memory of the original module. Further,the character continues to be controlled by the processor of theoriginal module. The module to which the character's image has movedtransmits information about itself (e.g., other simulated objectsdisplayed by the module, properties or rules of the module, etc.) to themodule controlling the character. That module's processor determines thecharacter's next action and transmits the information to the moduledisplaying the character. The information can be transmitted directly tothat module's display or to the displaying module's processor.

Alternatively, when a character's image moves to a new module,information for the character is transmitted to the new module's memoryand the new module's processor takes over control of the character'sactions. Preferably, a copy of the character's information ispermanently stored on the original module, and in the event that theoriginal module is separated from the module containing the character,the character can be reinitialized in the original module. Preferably,the character will continue to exist in the non-original module untilsome event (e.g., a power failure) causes the character to cease toexist; however, the character can cease to exist as a direct result ofits original module being separated from the module it is in.

Alternatively, the original module can delete the character from memoryand not retain a permanent copy. As a result, in the event that theinitial module is separated from the character, the character cannot bereinitiated in the original module.

Orientation Sensor

As illustrated by FIGS. 8A-D, a character simulation module 800 ispreferably, but not necessarily, equipped with an orientation sensor805. The orientation sensor 800 includes electrical connectors 810, 815,820, 825, 830, 835, 840 and 845, as well as a mobile, electricallyconductive member 850. Eight is the preferred number of connectors, butany suitable number of connectors greater than or equal to two can bepresent. When the character simulation module 800 is resting asillustrated in FIG. 8A, gravity causes the electrically conductivemember 850 to contact electrical connectors 830 and 835, enabling asignal to pass between the two connectors. Thus, the orientation sensor805 detects its orientation.

If the module 800 and orientation sensor 805 are rotated ninety degreescounterclockwise, as illustrated in FIG. 8B, gravity causes theelectrically conductive member 850 to contact electrical connectors 840and 845, enabling a signal to pass between the two connectors.Similarly, if the module 800 and orientation sensor 805 are againrotated ninety degrees counter-clockwise, as illustrated in FIG. 8C, theelectrically conductive member 850 is again moved by gravity and nowcontacts electrical connectors 810 and 815, enabling a signal to passbetween the two connectors. Another ninety degree counter-clockwiserotation places the module 800 and orientation sensor 805 in theposition illustrated by FIG. 8D. The electrically conductive member 850contacts electrical connectors 820 and 825, enabling a signal to passbetween the two connectors.

The electrically conductive member 850 is preferably a metal disk orsphere, but any suitable material (e.g., a conductive liquid such asmercury) can be used. Further, the electrically conductive member 850preferably only contacts two electrical connectors at a time at most.Alternatively, the electrically conductive member 830 can contact, andthus electrically couple, more than two electrical connectors at onetime.

The orientation sensor 805 enables the simulated character to react tochanges, or the lack thereof, in the orientation of the module 800. Forexample, if the module 800 is tilted to the left, an animation showingthe simulated character falling to the left and then standing up againis displayed. Similarly, if the module 800 is tilted to the right, ananimation showing the simulated character clinging to the left side ofthe display to prevent slipping to the right is shown. Further,sequences of changes in the module's 800 orientation can triggerdifferent animations. For example, rotating the module three hundredsixty degrees causes an animation of the simulated character actingdizzy to be shown. It should be noted that orientation sensor 805,having eight electrical connectors, can be capable of distinguishingdifferent orientation categories, the four substantially similar tothose illustrated and four additional orientations substantially similarto orientations reached by rotating any of the illustrated orientationsforty-five degrees. Other orientation sensors can resolve orientation todifferent resolutions.

In addition to, or instead of, triggering an animation, orientationchanges or sequences of orientation changes can trigger games, changeproperties of the simulated world, disable one or more input devices,cause input from one or more input devices to be ignored, turn off amodule display, or initiate any other suitable reaction. Further, thereaction triggered by a sequence of one or more orientation changes canvary depending on the state of the module, the simulated world, thenumber of interconnected modules, the configuration of theinterconnected modules and/or any other suitable condition. It should benoted that different characters can react differently to identicalconditions.

Sound Sensor

Preferably, a simulated character module has a sound sensor thatprovides the processor with audio input from the module's environment;however a sound sensor is not necessary to a module. The sound sensorenables a simulated character to react to noises. For example, if musicis playing (e.g., from a radio, a stereo system, a computer, a musicalinstrument, finger tapping on a table, etc.), the character begins todance, preferably in sync with the music; however, a character can dancewithout being in sync with the music.

In addition to, or instead of, causing a character to dance, audio input(e.g., a spoken word, a clapping sound, a whistle, a tone, etc.) cantrigger games, change properties of the simulated world, disable one ormore input devices, cause input from one or more input devices to beignored, turn off a module display, or initiate any other suitablereaction. Further, the reaction triggered by an audio input can varydepending on the state of the module, the simulated world, the number ofinterconnected modules, the configuration of the interconnected modulesand/or any other suitable condition. It should be noted that differentcharacters can react differently to identical conditions.

FIG. 9 shows a process of operating a simulated character module thathas a sound sensor. At step 900, it is determined whether the soundsensor detects a sound. If the sound sensor does not detect a sound, theprocess repeats at step 900. If the sound sensor detects a sound, atstep 910, it is determined whether the sound is associated with asimulated character module action. Simulated character module actionsinclude, but are not limited to, causing a character to exhibit abehavior, triggering a game, changing a property of the simulated world,disabling one or more input devices, causing input from one or moreinput devices to be ignored, turning off a module display or any othersuitable reaction. If the sound is not associated with a simulatedcharacter module action, the process repeats at step 900. If the soundis associated with a simulated character module action, at step 920, theaction is executed and the process repeats at step 900.

Preferably, a simulated character module has a sound generating devicesuch as a piezo buzzer or a speaker; however, a module can have anyother suitable sound generating device, any suitable vibration device orno sound generation capability. Preferably, a simulated character modulecan detect and react to one or more sounds made by another simulatedcharacter module.

Light Sensor

Similarly, a simulated character module preferably has a lightgenerating device such as an LED, a flash bulb or a laser; however, amodule can have any other suitable light generating device or no lightgeneration capability. A simulated character module can preferablydetect and react to light emitted by another simulated character module.

Preferably, a simulated character module has a light sensor thatprovides the processor with visual input from the module's environment;however a light sensor is not necessary to a module. Preferably, thelight sensor detects the level of light and/or brightness in themodule's environment; however, the light sensor can be more complex(e.g., a video camera) or any other suitable light detecting inputdevice. The light sensor enables a simulated character to react tovisual input from the environment. For example, if the light is bright(e.g., daytime or the room lights are on), the character becomes activeand if the light is dim or off (e.g., nighttime or room lights are off),the character goes to sleep. It should be noted that the character canengage in any other suitable behavior as a result of the input providedby the light sensor. Further, different characters can react differentlyto identical conditions.

Further, input from the light sensor can trigger games, changeproperties of the simulated world, disable one or more input devices,cause input from one or more input devices to be ignored, turn off amodule display, or initiate any other suitable reaction. Also, thereaction triggered by input from the light sensor can vary depending onthe state of the module, the simulated world, the number ofinterconnected modules, the configuration of the interconnected modulesand/or any other suitable condition.

FIG. 10 shows a process of simulating a character that reacts to lightlevels. At step 1000, a light sensor detects a light level from theenvironment around a simulated character module. At step 1010, it isdetermined whether the light level is associated with a simulatedcharacter behavior. Simulated character behaviors include, but are notlimited to, sleeping, playing, praying, dancing, eating, singing,working, mating, bathing, showering, grooming, dressing, flinching,shielding the character's eyes, changing a facial expression or anyother suitable reaction. If the light level is not associated with asimulated character behavior, the process repeats at step 1000. If thelight level is associated with a simulated character behavior, at step1020, the behavior is executed and the process repeats at step 1000.

Preferably, simulated character module can also react to the rate ofchange and/or frequency of change of the light level. For example, ifthe light level increases rapidly (e.g., a light is turned on in a darkroom containing the module), the module can cause a simulated characterto rub its eyes or execute any other suitable reaction. Similarly, ifthe light level drops rapidly, the module can cause a simulatedcharacter to stumble around blindly or execute any other suitablereaction. If the light level fluctuates erratically (e.g., the onlysource of light is lightning flashes in a thunderstorm), the module cancause simulated rain to occur in the simulated world or execute anyother suitable reaction. Similarly, if the light level fluctuatesregularly (e.g., the source of light is a strobe light), the module cancause the simulated character to dance or execute any other suitablereaction.

Input from the light sensor can preferably be used together with otherinput sensors to produce more complex module and/or simulated characterreactions; however, the light sensor can be used alone to produce anysuitable module and/or simulated character reactions if desired. Forexample, if the light level suddenly increases when a time device of themodule indicates that it is night time, the module can cause thesimulated character to pull down a simulated shade or close simulatedblinds on the display or execute any other suitable reaction. Similarly,other input devices can be used alone or together to produce anysuitable module and/or simulated character reactions if desired.

Time Device

Preferably, a simulated character module has a time device or clock thatprovides the processor with chronological information; however a timedevice is not necessary to a module. Preferably, the time device is astandard clock that can be set and keeps track of the time and/or date;however, the time device can be more complex (e.g., a clock set bysignals from the atomic clock) or any other suitable time device. Thelight sensor enables a simulated character to react to the time of dayand/or time of year. For example, at night the character becomessocially active and in the day the character goes to work. Similarly, onJuly Fourth, the character can set off fireworks, or on New Year's Eve,the character can wear a lamp shade on its head and dance all night. Itshould be noted that the character can engage in any suitable behavioras a result of the time of day and/or time of year. Further, differentcharacters can react differently to identical conditions.

Further, input from the time device can trigger games, change propertiesof the simulated world, disable one or more input devices, cause inputfrom one or more input devices to be ignored, turn off a module display,or initiate any other suitable reaction. Also, the reaction triggered byinput from the time device can vary depending on the state of themodule, the simulated world, the number of interconnected modules, theconfiguration of the interconnected modules and/or any other suitablecondition.

FIG. 11 shows a process of simulating a character that reacts hasdifferent behaviors depending upon the time or date. At step 1100, atime device provides the processor with chronological information. Atstep 1110, it is determined whether the time or date are associated witha simulated character behavior. Simulated character behaviors include,but are not limited to, sleeping, playing, praying, dancing, eating,singing, working, mating, bathing, showering, grooming, dressing,singing, drinking, setting off fireworks, waving a flag, wearing a lampshade as a hat, wearing a costume, fasting, attending a religiousservice, marrying, playing an instrument and/or a song (e.g., taps),giving a gift, parading, grilling or any other suitable reaction. Ifneither the time nor the date is associated with a simulated characterbehavior, the process repeats at step 1100. If time or date isassociated with a simulated character behavior, at step 1120, thebehavior is executed and the process repeats at step 1100

Simulated Character Interaction

Preferably, two or more simulated characters from differentinterconnected modules are able to interact. For example, two characterscan participate in a game, dance, fight, race, exchange information,engage in a competition, exchange virtual goods or services, becomefriends, date, give each other gifts, produce offspring, or engage inany other suitable interaction. The type of interaction is preferablyinfluenced by characteristics of the simulated characters, configurationof the modules, characteristics of one or more modules, and/orenvironmental input; however, the type of interaction can be determinedin any suitable manner.

Preferably, a user can control or influence the interaction by providinginput to the modules. A user can provide input by using one or morebuttons, making a sound, flashing a light, changing the modules'orientation, adding or removing modules, or any other suitable means ofproviding input to the modules. However, a user can also be unable toinfluence or control the interaction.

Game interactions can be any suitable type of game. For example, whentwo or more simulated character modules are connected, the simulatedcharacters can play against each other in a game (e.g., checkers, chess,a race, card games, fighting games, or any other suitable game).Alternatively, the characters can be pieces in a game played by one ormore users.

For example, users can connect, directly or indirectly, two modules, andthe simulated characters of those modules can compete. Preferably, thelosing character is transferred to the winning character's module, orsome other module owned by the same player; however, the losingcharacter can simply be deleted from its module and the winning playercan be rewarded in another manner (e.g., by improving the competitiveworth of the winning character) or any other suitable set of actions canexecute. The module of the loser is preferably able to reinitiate asimulated character; however, the module can be unable to reinitiate asimulated character. Such a module would remain empty until anothersimulated character is transferred to it. The outcome of the competitionbetween characters can be deterministic, but preferably there is arandom or pseudorandom element to the outcome. The objective of such agame would be to amass a valuable collection of simulated characters.

In another game, each player can have more than one simulated characteras a piece in the game. For example, the modules can be used to play agame similar to fantasy or other theme-based card games (e.g., Magic theGathering, Illuminati, etc.). Preferably, players take turns adding oneor more modules to the interconnected group. Game play is preferablyinfluenced by the characters in the modules added, the location to whichthe modules are added, a random or pseudorandom number generator, inputfrom the players (e.g., via buttons or other sensors) and/or input fromthe environment (e.g., orientation, sound, light, etc.). However, gameplay can be conducted in any suitable manner.

FIG. 12 shows a process for playing a game in which simulated charactersare pieces of the game in accordance with one embodiment of the presentinvention. The game is preferably a two player game, as illustrated;however, the game can have more than two players, if desired. At step1200, a simulated character module of Player A is connected to asimulated character module of Player B. The modules are configured suchthat their connection initiates play of the game. Preferably, no othermodules are connected to either the module of Player A or the module ofPlayer B when they are connected; however, game play can be conductedsuch that one or more other modules are connected to one or both of themodules of Player A or Player B when the modules are connected.

Preferably, the game includes turns during which players can takeactions; however, the game can include rounds, simultaneous play and/orany other suitable system for advancing game play. At step 1205, it isdetermined whether it is Player A's turn. If it is Player A's turn, atstep 1210, Player A can connect another module to the group ofinterconnected modules. At step 1215, one or more of Player A'ssimulated characters can act. The simulated character actions can bedirected by Player A (e.g., through instructions input through inputdevices on one or more modules; however, the simulated character actionscan be determined by the configuration of the interconnected modules, bya random or pseudo-random event or in any other suitable manner. Theactions can include attacking Player B's simulated characters, defensesor game points, building defenses for Player A, maneuvering, waiting,casting spells or any other suitable action. Preferably, some actionscan result in the simulated character moving between modules andinteracting with (e.g., fighting with or attacking) other characters.

At step 1220, it is determined whether a game ending event has occurred.If a game ending condition has occurred, at step 1225, the game is over.If not, the process repeats at step 1205.

If, at step 1205, it is determined that it is not Player A's turn, atstep 1230, it is determined whether it is Player B's turn. If it is notPlayer B's turn, the process repeats at step 1205. If it is Player B'sturn, at step 1235, Player B can connect another module to the group ofinterconnected modules. At step 1240, one or more of Player B'ssimulated characters can act and the process continues at step 1220.Preferably, once a module is connected to the group of interconnectedmodules, the module is not removed until game play ends; however,modules can be removed at any suitable time during game play if desired.

The game can also be a simulation. The user can connect two or moremodules and simply observe the simulated characters actions andinteractions in their simulated world, similar to watchinginterconnected ant farms or hamster habitats. Modules can be added tointroduce new characters into the world and/or to provide newinteraction options. For example, one module can enable characters inthe simulated world to dance, another module can enable characters toreproduce, and other modules could give characters the ability to engagein other suitable interactions.

Simulated Character Generation

Preferably, a user can influence or control character attributes thatare present when the character is created or generated; however,character attributes present at character generation can alternativelybe uninfluenced by a user. Attributes present at character generationcan include the way the character looks, communicates or acts in thesimulated environment. Further, a character is preferably normallydisplayed in stick form, but when the character wants to communicate tothe world outside of the simulated environment, it brings its head tothe full screen. As a result, facial features, expressions or movementscan be displayed in greater detail. Such facial features, expressionsand movements can be attributes that a user can influence or controlupon character generation. Further still, the simulated character cancommunicate with the real world (e.g., the user) via text. The text ispreferably displayed in cartoon bubbles when the character brings itshead to the full screen; however, the text can be presented in anysuitable manner at any suitable time.

Preferably, the character that is generated as a result of the userinfluencing one or more character attributes (e.g., appearance,temperament, language, dialect, education level, etc) can move to otherusers' modules. The character can then cohabit in the host module andinteract with the host module's characters. Preferably, the moduleincludes a “clone” function which enables a user to keep his or hercreation on one module and have one or more copies travel to othermodules. Preferably, the amount of memory necessary to store a characteris relatively small compared to the total available memory for a module.As a result, many simulated characters can coexist in the same module.

Preferably, a simulated character attributes generator enables efficientusage of the system uC volatile memory resources with regards tocharacter generation and storage. Attributes are preferably formed inelements and built up into a character profile, similar to police “photofit” systems. Character profiles can be generated in accordance withrandom and/or user input. Alternatively a character profile can be adefault profile.

Preferably, one or more attributes are represented as memory addressedpixel patterns in the uC ROM; however, attributes can be represented inany suitable manner and in any suitable device. Further, characters arepreferably treated as sprites, enabling simple internal code commandsmove them around the screen; however, characters can be displayed as anytype of graphical representation and can be manipulated in any suitablemanner.

Preferably, firmware forms a “Virtual World” generator engine, which hasa number of interaction routine libraries available; however, thegenerator engine can be hardware or software and need not include anylibraries, if desired. Preferably, the attributes of a particularcharacter (e.g., character personality/behavior weights or values)further modify these routines, thereby providing changing play-patterns.

Generated characters can be stored in system registers/RAM, orpreferably in flash memory, where they could survive a long termpower-down; however, characters can be stored in any suitable storagedevice.

Character attributes can be any suitable variable or fixed size. As anexample, each attribute can be an 8-bit element (1 byte). Using suchattributes, an exemplary unique character can be stored using 5 bytes,though, it should be understood that unique characters could be storedusing more or fewer bytes, depending upon the size and number ofattributes. Byte 1 of the exemplary character represents hair style/headgear (e.g., hat) information. Byte 2 represents facial information. Byte3 represents body information. Byte 4 represents arm and leg typeinformation, with the lower four bits representing the arm type and theupper four bits representing the leg type. The lower four bits of Byte 5represent vocabulary, dialect and/or language abilities of thecharacter. The upper four bits of Byte 5 represent Characterpersonality/behavior information.

Preferably, geographic territories can use specific parts of the bytesfor their own regional attribute variations. For example, bits 00 h to64 h of the facial information byte can represent facial features withAmerican/English characteristics. Similarly, bits 65 h to C8 h canrepresent facial features with Asian characteristics. As a result, amodule distributed to an American/English user (or a user in apredominantly American/English geographic region) is preferably unableto generate oriental characters; however, modules can be configured toallow any type of character to be configured in any suitable region, ifdesired. Preferably, characters from other territories can still beseen, stored upon and pass through all modules, and only the charactergenerator functionality does not give access to the library attributesspecific to other territories. As a result, characters that cannot begenerated in one territory may become valuable and/or sought afterwithin that territory as rare, difficult to acquire characters.

It should be understood that various changes and modifications to thepresently preferred embodiments described herein will be apparent tothose skilled in the art. Such changes and modifications can be madewithout departing from the spirit and scope of the present invention andwithout diminishing its intended advantages. It is therefore intendedthat such changes and modifications be covered by the appended claims.

1. A module, comprising: a processor; and a memory unit that stores oneor more computer-readable instructions, that when executed by theprocessor, implement a method, the method comprising: selectivelydisplaying a first animation sequence of a first simulated characterbased on a first set of at least one of character attributes andbehaviors; receiving connection information indicating a physicalconnection status of the module with a second module; and in response tothe connection status, processing module information associated with thesecond module; modifying the first animation sequence based on themodule information and the first set of at least one of characterattributes and behaviors; and displaying the modified animationsequence.
 2. The module of claim 1, further in response to theconnection status, transmitting character animation information to thesecond module based on the module information and the first set of atleast one of character attributes and behaviors.
 3. The module of claim1, further in response to the connection status, receiving the moduleinformation from the second module.
 4. The module of claim 1 wherein themodule information includes character animation information that enablesthe display of an animation sequence of a second simulated characterbased on a second set of at least one of character attributes andbehaviors.
 5. The module of claim 1 wherein the module informationincludes properties of the second module.
 6. The module of claim 1wherein the method further comprises receiving sensor input information,and in response to the sensor input information, selectively modifyingat least one of the animation sequence and the modified animationsequence.
 7. The module of claim 6 wherein the sensor input informationincludes at least one of light sensor information, sound sensorinformation, and orientation sensor information.
 8. A computer programproduct, the computer program product comprising: a computer-readablestorage medium that stores computer-readable instructions, that, whenexecuted, implement a method for controlling an animation, the methodcomprising: selectively displaying on a first module a first animationsequence of a first simulated character based on a first set of at leastone of character attributes and behaviors; receiving connectioninformation indicating a physical connection status of the first modulewith a second module; and in response to the connection status,processing module information associated with the second module;automatically modifying the first animation sequence based on the moduleinformation and the first set of at least one of character attributesand behaviors; and displaying the modified animation sequence.
 9. Thecomputer program product of claim 8, further in response to theconnection status, transmitting character animation information to thesecond module based on the module information and the first set of atleast one of character attributes and behaviors.
 10. The computerprogram product of claim 8, further in response to the connectionstatus, receiving the module information from the second module.
 11. Thecomputer program product of claim 8 wherein the module informationincludes character animation information that enables the display of ananimation sequence of a second simulated character based on a second setof at least one of character attributes and behaviors.
 12. The computerprogram product of claim 8 wherein the module information includesproperties of the second module.
 13. The computer program product ofclaim 8 wherein the method further comprises receiving sensor inputinformation, and in response to the sensor input information,selectively modifying at least one of the animation sequence and themodified animation sequence.
 14. The computer program product of claim13 wherein the sensor input information includes at least one of lightsensor information, sound sensor information, and orientation sensorinformation.
 15. A method of animating a simulated character, the methodcomprising: selectively displaying on a first module a first animationsequence of a first simulated character based on a first set of at leastone of character attributes and behaviors; receiving connectioninformation indicating a physical connection status of the first modulewith a second module; and in response to the connection status,processing module information associated with the second module;automatically modifying the first animation sequence based on the moduleinformation and the first set of at least one of character attributesand behaviors; and displaying the modified animation sequence.
 16. Themethod of claim 15 further in response to the connection status,transmitting character animation information to the second module basedon the module information and the first set of at least one of characterattributes and behaviors.
 17. The method of claim 15, further inresponse to the connection status, receiving the module information fromthe second module.
 18. The method of claim 15 wherein the moduleinformation includes character animation information that enables thedisplay of an animation sequence of a second simulated character basedon a second set of at least one of character attributes and behaviors.19. The method of claim 15 wherein the module information includesproperties of the second module.
 20. The method of claim 15 furthercomprising receiving sensor input information, and in response to thesensor input information, selectively modifying at least one of theanimation sequence and the modified animation sequence.
 21. The methodof claim 20 wherein the sensor input information includes at least oneof light sensor information, sound sensor information, and orientationsensor information.